The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.
In order to synchronize personal information or corporation data between multiple platforms and networks, the industry has paid more attention to the development of SyncML. The use of SyncML can make a user, a device developer, a component developer, a data provider, an application developer and a service provider cooperate with each other, and enable network data to be accessed by any client anywhere at any moment.
A typical application of the SyncML initiative is the data synchronization between a mobile device and a network service device. Besides the abovementioned application, the SyncML initiative is applicable to the data synchronization between two equivalent devices, such as two computers. FIG. 1 shows a schematic diagram illustrating data synchronization between a client and a server. As shown in FIG. 1, the data synchronization includes the following processes. After a negotiation of device information at an initialization phase of the synchronization, the client sends the data changed by the client to the server for storing, and the server sends the data changed by the server to the client for storing, so as to guarantee the data synchronization between the client and the server.
At present, there are many types of data synchronization between the client and the server, such as two-way synchronization, slow synchronization, one-way synchronization from client, refresh synchronization from client, one-way synchronization from server, refresh synchronization from server and server alerted synchronization.
The processes of two-way data synchronization are hereinafter described as follows. FIG. 1 is a message flow schematic diagram illustrating two-way data synchronization between a client and a server in the prior art. FIG. 1 includes the following steps:
Step 100: a client sends a synchronization initialization package to a server.
Step 101: the server sends the synchronization initialization package to the client.
In steps 100 and 101, a synchronization initialization is performed. The synchronization initialization includes the following: authentication, synchronization data negotiation, device information negotiation etc. The device information negotiation determines what data format can be synchronized, and which synchronization types are supported.
Step 102: the client sends synchronization data to the server.
Step 103: the server sends synchronization data to the client.
In steps 102 and 103, the client sends changed data to the server based on change state of the data. The change state of the data may be Add, Update, Delete, Move etc. The server modifies the data stored in the server according to the data received from the client, so that the server fulfils the data synchronization. The server also sends the changed data to the client based on the change state of data stored in the server, and the client modifies the data stored in the client according to the data received from the server, so that the client fulfils the data synchronization.
Step 104: after receiving the synchronization data, the client sends a synchronization acknowledgement message to the server.
Step 105: after receiving the synchronization data, the server sends synchronization acknowledgement message to the client.
FIG. 2 shows a schematic diagram illustrating a system for implementing data synchronization in the prior art. As shown in FIG. 2, the system includes a client and a server. The client can perform message interaction with the server. On the client side, there is also a client database for storing the data needed by a user of the client. The client database can be set in the client or can be set separately. On the server side, there is also a server database for storing the data of the server. The server database can be set in the server or can be set separately.
In general, the client can be an intelligent terminal, such as a computer, a mobile terminal or a Personal Digital Assistant (PDA). The data stored in the database at the client side may include: contacts, calendars, notes, emails etc. There are standard data formats for all of the above data. The client can convert the stored data into standard data format, and send the converted data to the server. After the received data is processed by the server, the server may store the processed data into the database at the server side. In general, the server can be a computer or a network server performing data synchronization. The server can receive a data synchronization message or a data synchronization command from the client; or the server can send a data synchronization message or a data synchronization command to the client. The steps of data synchronization between the client and the server are simply described above. The client and the server need to negotiate device capability at the initialization state of the data synchronization, and the steps of the negotiation are described as follows.
A client sends a server a data synchronization initialization message (SyncML Initialization Message) carrying the device information of the client. Alternatively the SyncML Initialization Message is used to request device information of the server. The device information of the client is contained in <Result> command of the SyncML Initialization Message, while a request for device information of the server is carried in <Get> command of the SyncML Initialization Message. If the client does not need the device information of the server, the <Get> command will not be sent to request device information of the server. Otherwise, in response to the request of the client, the server carries the device information of the server in a response to the SyncML Initialization Message.
Likewise, the server can also request the device information of the client from the client. The detailed steps are described as follows.
A client sends a SyncML Initialization Message to a server to request device information of the server. The server sends the client a response to the SyncML Initialization Message, and the response carries the device information of the server, and a request for device information of the client. The device information of the server is contained in <Results> command of the response to the SyncML Initialization Message; while a request for the device information of the client is contained in <Get> command of the response to the SyncML Initialization Message. The client sends the SyncML Message containing the device information of the client to the server. The <Results> command of the SyncML Message carries the device information of the client.
The device information of the client and the device information of the server are mainly used for a content adaptation. For example, both the client and the server support communication synchronization, but the device information supported by the clients of different manufacturers is different, for example, the versions of the contacts supported are different, or fields supported are different although the versions supported are the same, negotiation of the device capability between the server and the client should be performed, the client and the server can determine the device capability each other, and the contents adaptation can be performed and the data synchronization can be implemented between the client and the server.
A data structure of the device information is shown in FIG. 3. The device information related to device includes: a device manufacturer, a device model, a software version number, a hardware version number and device type. The device information related to synchronization data includes: a device model, supported types of synchronization data, supported properties of synchronization data, supported values of the properties, supported parameters of synchronization data, etc. The device information relates to data storage includes: a Uniform Resource Identifier (URI) of local data storage, a maximum length of Globally Unique Identifier (GUID), data storage capacity and supported synchronization type. The device information related to extension mechanism includes: a name of a custom extended element, and a value of the custom extended element.
After the device information is described in a markup language, the device information may be stored into the database at server side or be stored into the database at client side, or the device information may be used in an interaction between the client and the server.